The Internet is a conglomeration of Autonomous Systems (AS) or domains that define the administrative authority and the routing policies of different organizations. These domains consist of routers that run Interior Gateway Protocols (IGPs) such as Routing Information Protocol (RIP), Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), and Intermediate System-to-Intermediate System (IS-IS) within their boundaries. Neighbouring domains are interconnected via an Exterior Gateway Protocol (EGP); the current Internet standard EGP is the Border Gateway Protocol Version 4 (BGP-4) defined in RFC 4271.
Exterior routing protocols were created to control the expansion of routing tables and to provide a more structured view of the Internet by segregating it into separate administrations, or domains, each with their own independent routing policies and unique IGPs.
These routing protocols define how routers determine their ‘map’ of the network and from which they can compute the shortest path to a destination, allowing routing to be a largely automatic process. However, the shortest path is not always the fastest or the best. Traffic Engineering (TE) is the process where data is routed through the network according to the availability of resources and the current and expected traffic. The required quality of service (QoS) can also be factored into this process.
Traffic Engineering may be under the control of operators whereby they monitor the state of the network and route the traffic, or provision additional resources, to compensate for problems as they arise. Alternatively, Traffic Engineering may be automated. Traffic Engineering helps the network provider make the best use of available resources, spreading the load over the layer 2 links, and allowing some links to be reserved for certain classes of traffic or for particular customers.
New technologies such as Traffic Engineered Provider Backbone Bridging (PBB-TE), and more standardized ones, such as Multi-Protocol Label Switching (MPLS) and its extensions (i.e. GMPLS, T-MPLS), provide efficient TE solutions within a single domain (i.e. intra-domain) thanks to their connection oriented nature. However, in order to support all available services end-to-end, future packet switched network architectures need to guarantee both suitable QoS and efficient use of resources between networks. This requires routing solutions that can apply Traffic Engineering for the entire path, end-to-end, both within and between domains.
The traditional approach for inter-domain TE routing is based on BGP-TE (see IETF draft-fedyk-bgp-te-attribute-03—“Traffic Engineering Attribute”). However, this method is only capable of applying TE constraints to computation of the inter-domain paths and to the intra-domain paths of the source and destination domains. BGP-TE does not consider detailed information relating to the intra-domain paths within any transit domains, which must be traversed to reach the destination. In addition, in a BGP-based approach, complex policy constraints can be configured, but are mostly targeted to peering agreements and economical or administrative choices. TE constraints such as maximum overload on a link and congestion occurring on a transit link are still not supported.
U.S. Ser. No. 09/981,138 discloses a system for end-to-end path computation taking into consideration detailed network resource information in the source and destination domains, while transit domains are selected according to traditional BGP-TE. BGP-TE floods the network with aggregate information in terms of routes and TE weights and, as a result, the lack of detailed information on transit domains does not allow for efficient end-to-end TE path computation.
The computation of an end-to-end path taking into account several constraints (such as QoS, bandwidth, priority, protection, etc.) in a multi-domain scenario is a very difficult issue. Detailed information is required from each domain in order to compute efficient paths using TE; the more detailed this information the more path computation meets TE requirements. This has obvious problems of scalability when expanding to incorporate more domains. In addition, a lot of intra-domain information (e.g. state of links, topology, administrative policies, etc.) is preferably confidential such that the owners/administrators of a domain would not want to share such details with other domains or administrative entities external to the domain. For these reasons the use of sophisticated intra-domain TE strategies is limited when applied to the computation of end-to-end inter-domain paths.
Standardization bodies, such as the IETF, are working on the definition of communication protocols and related architectures to deal with the multi-domain network scenario. These are based on a client-server architecture where a generic entity named the Path Computation Client (PCC) represents the client performing the path request, while the Path Computation Element (PCE) is the entity receiving the request and performing the path computation (see IETF RFC 4655—“A Path Computation Element (PCE)-based architecture”). The standards define a communication protocol and the requirements to be satisfied (such as protection type, priority, colour, etc.), while the solution to satisfy such requirements in a multi-domain scenario is outside of the scope of the standardization work.